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(54) MPEG flow identification for IP networks 

(57) The payloads of I P packets are checked to ac- 
tually determine if a packet contains M P EG-2 video rath- 
er than using predefined streams or priority levels that 
are assumed to contain such information as is done in 
the prior art. More specifically, the "sync" bytes of the 
MPEG-2 stream are searched for within the IP packet 
payload, and when a pattern indicative of the sync bytes 
is found the sync bytes are identified and the packet is 



determined to contain MPEG-2 video. The sync byte 
was defined in MPEG-2 for over-the-air broadcasting in 
order that a television receiver be able to synchronize 
the MPEG-2 transport stream packets. Note that the 
MPEG-2 video, e.g., the MPEG-2 transport stream 
packets, may or may not be incorporated within real time 
protocol (RTP) packets before being incorporated into 
the IP packets. 
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Description 
Technical Field 

[0001] This invention relates to the art of transmitting 5 
real-time-constrained information over internet protocol 
(IP) networks, and more particularly, to identifying par- 
ticular streams of real-time-constrained information, 
such as video encoded using Motion Pictures Expert 
Group (MPEG)-2 encoding, so that they may be given 
appropriate processing treatment. 

Background of the Invention 

[0002] A problem in the art of transmitting packets 
containing real-time-constrained information over inter- 
net protocol (IP) networks is the need to give each type 
of information the appropriate processing. In order to do 
this, it is necessary to know the type of information that 
is contained within each packet as it passes through the 
network at each point at which the packet will be proc- 
essed. In particular, video, such as using Motion Pic- 
tures Expert Group (MPEG)-2 encoded video, cannot 
withstand dropped packets. Therefore, in processing 
streams of packets that contain MPEG-2 video, it is nec- 
essary to give priority to any MPEG-2 video streams 
over other streams which are less sensitive, or insensi- 
tive, to dropped packets. 

[0003] Prior art techniques prioritize packets based 
on predefined criteria without actually ascertaining, e. 
g., by investigating the contents of the packet, that the 
packets actually contain MPEG-2 video. For example, 
a packet flow may be defined and it is assumed that all 
packets in that flow are MPEG-2 packets, and packets 
from that flow are treated as if they contain MPEG-2 
packets without regard for their actual contents. A flow 
is often defined by specifying source and destination IP 
addresses for the flow, or by specifying the source/des- 
tination port address thereof. 

[0004] Another prior art technique that is used to pri- 
oritize packets is based upon the so-called "type-of- 
service" (TOS) byte, which is part of the IP packet head- 
er. The TOS may be used to indicate a coarse prioriti- 
zation, so that, for example, it is assumed that any pack- 
et with either a predefined value in the TOS byte, or a 
value in the TOS byte that is at least a predefined value, 
contains MPEG-2 video and is treated appropriately. 
[0005] Because these prior art techniques do not ac- 
tually investigate the contents of the packet to be certain 
that it contains MPEG-2 video, it is possible that packets 
that do not contain MPEG-2 video will be processed as 
if they contained MPEG-2 video. Provided that there is 
sufficient bandwidth in the processing system, process- 
ing these non-MPEG-2 packets, i.e., these fake MPEG- 
2 packets, as if they were indeed actual MPEG-2 pack- 
ets is not a problem. However, in the face of limited 
bandwidth — and what system does not have limited 
bandwidth — processing these fake MPEG-2 packets as 



undroppable actual MPEG-2 packets unnecessarily 
consumes system resources. Furthermore, these prior 
art prioritization arrangements can be abused by an un- 
scrupulous user who sets his flow, or TOS byte, to indi- 
cate that he is sending MPEG-2 video, when in reality 
he is not. 

[0006] In addition, setting up the flows in an IP net- 
work — the flows being a static configuration that spec- 
ifies fixed ports — requires administration and/or recon- 
figuration each time a flow needs to be changed, i.e., a) 
when a point to point connection changes one of its 
points, b) when a new connection is made, ore) the like. 
Note that each switch or processing unit through which 
an MPEG-2 video stream flows must be updated with 
the new flow identifying information each time a flow 
needs to be changed. Thus, there is a constant admin- 
istrative burden due to the resulting flow churn. 
[0007] Another problem that arises in prior art ar- 
rangements using the TOS byte to define a flow that is 
to contain MPEG-2 video is the need for all of switches 
or processing units through which the flow passes to 
agree to a common TOS byte value, or set of values, 
that indicate MPEG-2 video. Otherwise, some switches 
or processing units may not properly handle, e.g., may 
drop, the MPEG-2 packets. It is difficult in practice to 
arrange for such agreement, especially when the flow 
travels over multiple networks. 

Summary of the Invention 

[0008] We have recognized that that the problems 
with the prior art can be overcome, in accordance with 
the principles of the invention, by actually determining 
that a packet contains MPEG-2 video rather than using 
predefined streams or priority levels that are assumed 
to contain such information as is done in the prior art. 
More specifically, in accordance with an aspect of the 
invention, the "sync" bytes of the MPEG-2 stream are 
searched for within the IP packet payload, and when a 
pattern indicative of the sync bytes is found the sync 
bytes are identified and the packet is determined to con- 
tain MPEG-2 video. The sync byte was defined in 
MPEG-2 for over-the-air broadcasting in order that a tel- 
evision receiver be able to synchronize the MPEG-2 
transport stream packets. Note that the MPEG-2 video, 
e.g., the MPEG-2 transport stream packets, mayor may 
not be incorporated within real time protocol (RTP) 
packets before being incorporated into the IP packets. 

Brief Description of the Drawing 

[0009] In the drawing: 

FIG. 1 shows internet protocol (IP) packet that is of 
the general type for which a determination may be 
made as to whether or not it contains MPEG-2 video 
based only on the packet's IP data payload in ac- 
cordance with the principles of the invention; 
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FIG. 2 shows an expanded version of a portion of 
the packet shown in FIG. 1 ; and 
FIG. 3 shows an exemplary process, in flowchart 
form, for processing an IP packet to determine if it 
contains MPEG-2 video, in accordance with the 
principles of the invention. 

Detailed Description 

[0010] The following merely illustrates the principles 
of the invention. It will thus be appreciated that those 
skilled in the art will be able to devise various arrange- 
ments which, although not explicitly described or shown 
herein, embody the principles of the invention and are 
included within its spirit and scope. Furthermore, all ex- 
amples and conditional language recited herein are 
principally intended expressly to be only for pedagogical 
purposes to aid the reader in understanding the princi- 
ples of the invention and the concepts contributed by 
the inventor(s) to furthering the art, and are to be con- 
strued as being without limitation to such specifically re- 
cited examples and conditions. Moreover, ail state- 
ments herein reciting principles, aspects, and embodi- 
ments of the invention, as well as specific examples 
thereof, are intended to encompass both structural and 
functional equivalents thereof. Additionally, it is intended 
that such equivalents include both currently known 
equivalents as well as equivalents developed in the fu- 
ture, i.e., any elements developed that perform the 
same function, regardless of structure. 
[0011] Thus, for example, it will be appreciated by 
those skilled in the art that the block diagrams herein 
represent conceptual views of illustrative circuitry em- 
bodying the principles of the invention. Similarly, it will 
be appreciated that any flow charts, flow diagrams, state 
transition diagrams, pseudocode, and the like represent 
various processes which may be substantially repre- 
sented in computer readable medium and so executed 
by a computer or processor, whether or not such com- 
puter or processor is explicitly shown. 
[0012] The functions of the various elements shown 
in the FIGs., including functional blocks labeled as 
"processors", may be provided through the use of ded- 
icated hardware as well as hardware capable of execut- 
ing software in association with appropriate software. 
When provided by a processor, the functions may be 
provided by a single dedicated processor, by a single 
shared processor, or by a plurality of individual proces- 
sors, some of which may be shared. Moreover, explicit 
use of the term "processor" or "controller" should not be 
construed to refer exclusively to hardware capable of 
executing software, and may implicitly include, without 
limitation, digital signal processor (DSP) hardware, 
read-only memory (ROM) for storing software, random 
access memory (RAM), and non-volatile storage. Other 
hardware, conventional and/or custom, may also be in- 
cluded. Similarly, any switches shown in the FIGS, are 
conceptual only. Their function may be carried out 
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through the operation of program logic, through dedicat- 
ed logic, through the interaction of program control and 
dedicated logic, or even manually, the particular tech- 
nique being selectable by the implementor as more spe- 
5 cifically understood from the context. 

[001 3] In the claims hereof any element expressed as 
a means for performing a specified function is intended 
to encompass any way of performing that function in- 
cluding, for example, a) a combination of circuit ele- 
10 ments which performs that function or b) software in any 
form, including, therefore, firmware, microcode or the 
like, combined with appropriate circuitry for executing 
that software to perform the function. The invention as 
defined by such claims resides in the fact that the func- 
tionalities provided by the various recited means are 
combined and brought together in the manner which the 
claims call for. Applicant thus regards any means which 
can provide those functionalities as equivalent as those 
shown herein. 

[0014] Unless otherwise explicitly specified herein, 
the drawings are not drawn to scale. 
[0015] FIG. 1 shows internet protocol (IP) packet 101 
that is of the general type for which a determination may 
be made as to whether or not it contains MPEG-2 video 
based only on the packet's IP data pay load in accord- 
ance with the principles of the invention. More specifi- 
cally, in accordance with an aspect of the invention, a 
search is performed for the "sync" bytes of the MPEG- 
2 stream within the IP packet data payload of packet 
101. When a pattern indicative of the sync bytes is 
found, the packet is determined to contain MPEG-2 vid- 
eo. Otherwise, the packet is determined to contain in- 
formation that is not MPEG-2 video. 
[001 6] Packet 1 01 has a series of headers which pre- 
cede IP data payload 111 . In particular, packet 101 con- 
tains IP header 105, which is 20 bytes long and unreli- 
able datagram protocol/transmission control protocol 
(UDP/TCP) header 107, which is 8 bytes long. Note that 
conventionally IP header 1 05 and UDP/TCP header 1 07 
are conventionally grouped together and referred to as 
the header for the IP packet. They are shown independ- 
ently in FIG. 1 for clarity of exposition and pedagogical 
purposes only. 

[0017] Note that IP packet 101, as shown, is a UDP 
packet. This is because, as of this writing, UDP is typi- 
cally used for real-time streaming, as TCP requires end- 
to-end communication. Thus, the invention is described 
herein in terms of UDP packets in IP. However, those of 
ordinary skill in the art will readily recognize how to apply 
the principles of the invention to TCP packets. 
[0018] IP data payload 111 follows UDPyTCP header 
109. The number of bytes that are contained within IP 
data payload 111 is flexible, ranging from 0 and up, al- 
though certain transmission arrangements, such as eth- 
ernet, may impose other limits. Optional real time pro- 
tocol (RTP) header 109, if present, is 12 bytes long, and 
is within IP data payload 111. 

[0019] FIG. 2 shows an expanded version of IP data 
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payload 111, which, as packet 101 is a UDP packet, is 
a UDP data payload. FIG. 2 shows an example in which 
UDP data payload 1 1 1 is carrying MPEG-2 video. As in- 
dicated, RTP header 109 may precede the MPEG-2 vid- 
eo within UDP data payload 111 . 
[0020] Consistent with any size limitations placed on 
it, UDP data payload 111 may carry any arbitrary number 
of MPEG-2 transport stream packets 201. Each of 
MPEG-2 transport stream packets 201 is 188 bytes in 
length. By virtue of the definition of the MPEG-2 trans- 
port layer, the first byte of each of MPEG-2 transport 
stream packets 201 is always a so-called "sync" byte 
203, which has the value of 0x47. 
[0021] In accordance with the principles of the inven- 
tion, due to the regular spacing of the sync byte, it is 
possible to search through UDP data payload 111 for 
the presence of the expected pattern of MPEG-2 video, 
i.e., a pattern of having a sync byte as the first byte of 
UDP data payload 111 — after any optional RTP head- 
er — and thereafter having a sync byte at each byte po- 
sition in UDP data payload 1 1 1 that is a multiple of 1 88. 
Although finding a sync byte as the first byte of UDP 
data payload 111 , after any optional RTP header, gives 
a strong indication that the IP packet contains MPEG-2 
video, and it is assumed that for UDP data payloads of 
length 1 88 for which the first byte has the value of a sync 
byte that the packet contains MPEG-2 video, preferably 
each potential sync byte position should be checked. 
This is because the confidence level that MPEG-2 video 
has actually been found increases substantially when 
each position indeed contains a sync byte value. 
[0022] I n the event that most of the expected positions 
contain a sync byte, but one or more do not, whether or 
not to declare the packet as one containing MPEG-2 vid- 
eo is at the discretion of the implementor when design- 
ing, or configuring, the system. For example, if only one 
position at which a sync byte would be expected was 
not a sync byte, and the IP packet was indicated to have 
a transmission error, then the implementor may decide 
to have the system still treat the packet as containing 
MPEG-2 video. 

[0023] FIG. 3 shows an exemplary process, in flow- 
chart form, for processing an IP packet to determine if 
it contains MPEG-2 video, in accordance with the prin- 
ciples of the invention. The process is entered in step 
301 when an IP packet is received. Next, in step 303, 
the packet is processed so there is a pointer that points 
to the UDP data payload within the packet, i.e., a pointer 
pointing within the packet is incremented to point to the 
UDP data payload. Thereafter, conditional branch point 
305 tests to determine if the length of the UDP data pay- 
load is a multiple of 1 88. If the test result in step 305 is 
YES, indicating that there is no RTP header and that the 
length of the UDP data payload corresponds to a multi- 
ple of the length of MPEG-2 transport stream packet, 
control passes to conditional branch point 307, which 
tests to determine if the byte of the UDP data payload 
being pointed to by the pointer has the value of a sync 
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byte, e.g., 0x47. 

[0024] If the test result in step 307 is YES, control 
passes to step 309, which increments the pointer 188 
bytes, i.e., the length of an MPEG-2 transport stream 
s packet. This should result in the pointer pointing either 
at a) the beginning of the next MPEG-2 transport stream 
packet or to the end of the UDP data payload, which is 
also the end of the packet, provided the UDP data pay- 
load actually contains MPEG-2 video, or b) just a ran- 
dom byte when the UDP data payload does not actually 
contain MPEG-2 video. Thereafter, control passes to 
conditional branch point 311, which tests to determine 
if the end of the IP packet has been reached. If the test 
result in step 311 is NO, indicating thatthere yet remains 
additional portions of the UDP data payload to process, 
control passes back to step 307 to process the rest of 
the packet as described above. If the test result in step 
31 1 is YES, control passes to step 313, and the IP pack- 
et is declared to be one containing MPEG-2 video, in 
accordance with an aspect of the invention. It may then 
be further processed accordingly. The process exits in 
step 315. 

[0025] If the test result in step 307 is NO, indicating 
that either the first byte or another byte at a 1 88 multiple 
position does not have the value of a sync byte, control 
passes to step 315 and the process is exited. 
[0026] If the test result in step 305 is NO, control pass- 
es to conditional branch point 317, which tests to deter- 
mine if the length of the UDP data payload is equal to a 
multiple of 188 plus the length of the RTP header. If the 
test result in step 317 is YES, indicating that the UDP 
data payload may contain an RTP header and thereafter 
MPEG-2 transport stream packets, control passes to 
step conditional branch point 319, which tests to deter- 
mine if the first bytes of the UDP data payload which 
correspond in length to an RTP header, have the char- 
acteristics of an RTP header, e.g., there is a video indi- 
cator in the location where the payload type field is ex- 
pected. More specifically, the payload type field is 7 bits, 
with the definition for MPEG-2 transport stream data be- 
ing 0x21. 

[0027] If the test result in step 319 is NO, which indi- 
cates that there was no RTP header or that the header 
was not indicative of video, control passes to step 315 
and the process is exited without declaring the I P packet 
to be one containing MPEG-2 video. If the test result in 
step 319 is YES, indicating that an RTP header for video 
was found, control passes to step 321 , in which the 
pointer is incremented to point to the first byte after the 
RTP header. Control then passes to conditional branch 
point 307 and the process continues as described 
above. 

[0028] If the test result in step 317 is NO, indicating 
that the IP packet does not contain a whole number of 
MPEG-2 video transport stream packets, control passes 
to step 323, in which a counter variable COUNT which 
is to be used as the offset into the UDP data payload, is 
set to 0. Next, conditional branch point 325 tests to de- 
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termine if COUNT is equal to the sum of 188 and the 
length of an RTP header. If the test result in step 325 is 
YES, indicating that all the positions that could poten- 
tially contain a sync byte of a first MPEG-2 video trans- 
port stream packet in the UDP data payload have been 
tested and not been found to be a sync byte, the process 
is exited in step 315, i.e., the packet is not declared to 
contain MPEG-2 video. If the test result in step 325 is 
NO, indicating that all the positions that could potentially 
contain a sync byte of a first MPEG-2 video transport 
stream packet in the UDP data payload have not been 
tested, control passes to conditional branch point 327 
in which another pointer, PACKTPT, is set to the value 
of COUNT. 

[0029] Thereafter, in step 329, the byte within the UDP 
data payload pointed to by PACKTPT is tested to deter- 
mine if it has the value of a sync byte. If the test result 
in step 329 is NO, indicating that the byte currently point- 
ed to by PACKTPT is not a sync byte, control passes to 
step 331 in which COUNT is incremented, so that it will 
point to the next byte in the UDP data payload. Control 
then passes back to step 325, and the process contin- 
ues as described above. 

[0030] If the test result in step 329 is YES, indicating 
that the byte currently pointed to by PACKTPT indeed 
has the value of a sync byte, control passes to condi- 
tional branch point 333, which tests to determine if the 
remaining number of bytes in the packet from the place 
being pointed to by COUNT is less than 1 88. If the test 
result in step 333 is YES, indicating that a whole MPEG- 
2 video transport stream packet cannot be contained 
within the UDP data payload, control passes to step 31 5 
and the process is exited, i.e., the packet is not declared 
to contain MPEG-2 video. If the test result in step 333 
is NO, indicating that a whole MPEG-2 video transport 
stream packet could be contained within the UDP data 
payload, control passes to step 335, in which PACKTPT 
is incremented by 188. 

[0031] At this point, if the UDP data payload indeed 
contains MPEG-2 video and the byte currently pointed 
to by COUNT is a sync byte, the byte pointed to by 
PACKTPT should also have the value of a sync byte, or 
at or beyond the end of the packet. To this end, condi- 
tional branch point 337 tests to determine if the end of 
the packet has been reached or is exceed. If the test 
result in step 337 is NO, indicating that PACKTPT points 
to a byte within the UDP data payload, control passes 
back to step 329 and the process continues as de- 
scribed above. If the test result in step 337 is YES, in- 
dicating that PACKTPT points to the end of the packet 
or beyond, control passes to step 313 and the process 
continues as described above. 
[0032] Note that the discussion herein with regard to 
IP refers to IP version 4, which is essentially universally 
in use as of the time of the writing of this application. 
Those of ordinary skill in the art will be readily able to 
apply the principles of the invention to later developed 
version of IP, such as proposed version 6, should one 
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be implemented. 



Claims 

5 

1. A method for processing an internet protocol (IP) 
packet, comprising the step of identifying that said 
packet contains motion picture expert group 
(MPEG)-2 video as a function of only the contents 

10 of said IP data payload of said IP packet. 

2. The invention as defined in claim 1 wherein said 
MPEG-2 video is in transport stream format. 

15 3. The invention as defined in claim 1 wherein said IP 
data payload contains at least one real time protocol 
(RTP) packet which contains said MPEG-2 video. 

4. The invention as defined in claim 1 wherein said IP 
20 data payload is a unreliable datagram protocol 

(UDP) data payload. 

5. The invention as defined in claim 1 wherein said IP 
data payload is a transmission control protocol 

25 (TCP) data payload. 

6. The invention as defined in claim 1 further compris- 
ing the step of processing said IP packet with a pri- 
ority assigned for packets containing video when 

30 said packet is identified in said identifying step to 
contain video. 

7. The invention as defined in claim 1 wherein said 
identifying step further includes the steps of: 

35 

determining whether or not there exists within 
said IP data payload at least an expected pat- 
tern of MPEG-2 sync bytes that is indicative of 
the presence of MPEG-2 video. 

40 

8. The invention as defined in claim 7 wherein said de- 
termining step further comprises the step of: 

comparing a first byte of said IP data payload 
45 after any real time protocol (RTP) header to the 

value of an MPEG-2 sync byte; and 
when the result of said comparing step is that 
said first byte of said IP data payload has the 
same value as an MPEG-2 sync byte, declaring 
so said IP packet to be an MPEG-2 packet. 

9. The invention as defined in claim 7 wherein said de- 
termining step further comprises the step of: 

55 comparing a first byte of said IP data payload 

after any real time protocol (RTP) header to the 
value of an MPEG-2 sync byte; and 
when the result of said comparing step is that 
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stream packet. 

The invention as defined in claim 7 wherein said de- 
termining step further comprises the step of: 



terminating said process and indicating that 
said expected pattern does not exist in said 
packet unless the length of said IP data payload 
or the length of said IP data payload less the 
length of a real time protocol (RTP) header is 
an integral multiple of the length of an MPEG- 
2 transport stream packet; 
pointing a pointer to a byte in said IP data pay- 
load, said byte being a first byte of said IP data 
payload when said length of said IP data pay- 
load is an integral multiple of the length of an 
MPEG-2 transport stream packet and said byte 
being a first byte of said IP data payload after 
the length of a real time protocol (RTP) header 
when said IP data payload less the length of a 
real time protocol (RTP) header is an integral 
multiple of the length of an MPEG-2 transport 
stream packet; 

performing a comparison between said byte 
being pointed to with the value of an MPEG-2 
sync byte and declaring said IP packet as a 
candidate to be an MPEG-2 packet when the 
result of a most recent comparison is that said 
pointed to byte of said IP data payload has the 
same value as an MPEG-2 sync byte 
adjusting said pointer to point to byte in said IP 
data payload that is offset toward the end of 
said IP packet by the length of an MPEG-2 
transport stream packet; 
repeating said performing and adjusting steps 
so long as said most recently executed per- 
forming step declared said IP packet as a can- 
didate to be an MPEG-2 packet and the end of 
said IP data payload is not yet reached; and 
declaring said packet to be an MPEG-2 packet 
when the end of said IP data payload is reached 
during an attempt to execute said adjusting 
step and said most recently executed perform- 
ing step declared said IP packet as a candidate 
to be an MPEG-2 packet. 

1 1 . The invention as defined in claim 7 wherein said ex- 
pected pattern is an MPEG-2 sync byte value 
spaced 188 byte positions apart. 

12. The invention as defined in claim 7 wherein said ex- 
pected pattern is an MPEG-2 sync byte value 
spaced apart by the length of an MPEG-2 transport 



declaring said IP packet to be an MPEG-2 
packet when a search over the length of a real 
time protocol header and the length of one 
MPEG-2 transport stream packet finds sync 
byte for which offset therefrom by the length of 
one MPEG-2 transport stream packet there is 
another sync byte. 

1 4. The invention as defined in claim 7 wherein said de- 
termining step further comprises the step of: 

declaring said IP packet to be an MPEG-2 
packet when a search over the length of a real 
time protocol header and the length of one 
MPEG-2 transport stream packet finds the val- 
ue of a sync byte for which offset therefrom at 
each integral multiple of the length of one 
MPEG-2 transport stream packet there is the 
value of a sync byte until the end of said IP 
packet is reached or exeeded. 

1 5. The invention as defined in claim 7 wherein said de- 
termining step further comprises the step of: 

declaring said IP packet to be an MPEG-2 
packet when a search over the length of a real 
time protocol header and the length of one 
MPEG-2 transport stream packet finds the val- 
ue of a sync byte for which offset therefrom by 
the length of one MPEG-2 transport stream 
packet there is the end of packet. 

16. The invention as defined in claim 7 wherein said 
each of said sync bytes has a value of 0x47. 

The invention as defined in claim 7 wherein said at 
least one expected pattern is the value of an MPEG- 
2 sync byte as the first byte of said IP data payload. 

45 1 8. The invention as defined in claim 7 wherein said ex- 
pected pattern is the value of an MPEG-2 sync byte 
as the first byte of said IP data payload and every 
1 88 bytes thereafter till the end of said IP data pay- 
load. 

50 

19. The invention as defined in claim 7 wherein said at 
least one expected patterns includes at least one of 
the sets of patterns consisting of: a) the value of an 
MPEG-2 sync byte as the first byte of said IP data 
55 payload after the length of a real time protocol 
(RTP) header and said IP data payload after said 
RTP header length has a length of 1 88 bytes, b) the 
value of an MPEG-2 sync byte as the first byte of 



said first byte of said IP data payload is an 
MPEG-2 sync byte and the length of said IP da- 
ta payload after any RTP header is the same 13. 
as the length of an MPEG-2 transport stream 
packet, declaring said IP packet to be an 5 
MPEG-2 packet. 

10. The invention as defined in claim 7 wherein said de- 
termining step further comprises the step of: 

10 
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said IP data payload after the length of a real time 
protocol (RTP) header and every 188 bytes there- 
after till the end of said IP data payload, c) the value 
of an MPEG-2 sync byte as the first byte of said IP 
data payload and every 188 bytes thereafter till the 
end of said IP data payload, d) the value of an 
MPEG-2 sync byte as the first byte of said IP data 
payload and said IP data payload has a length of 
188 bytes. 

20. A method for processing an internet protocol (IP) 
packet, comprising the steps of: 

searching through a payload of said IP packet 
for a pattern indicative of the presence of mo- 
tion picture expert group (MPEG)-2 video; and 
indicating that said IP packet contains MPEG- 
2 video only if said pattern is found. 

21. The invention as defined in claim 20 wherein said 
searching step further includes the step of: 

determining whether a payload of said IP pack- 
et has a length equal to an integral multiple of 
a length of an MPEG-2 transport stream packet 
either before or after subtracting from said pay- 
load length the length of an RTP head. 

22. The invention as defined in claim 20 wherein said 
searching step further includes the steps of: 

determining that a payload of said IP packet 
has a length equal to a length of an MPEG-2 
transport stream packet; 
comparing the value of a first byte at a first lo- 
cation within said packet with the value of an 
MPEG-2 sync byte; and 
signaling said pattern is found when the result 
of said comparing step is that said value of said 
first byte at said first location matches the value 
of said sync byte. 

23. The invention as defined in claim 20 wherein said 
searching step further includes the step of: 

determining whether a payload of said I P pack- 
et has a length equal to an integral multiple of 
a length of an MPEG-2 transport stream pack- 
et, 

comparing the value of a first byte at a first lo- 
cation within said packet and each byte at an 
offset of a length of an MPEG-2 transport 
stream packet therefrom with the value of an 
MPEG-2 sync byte; and 
signaling said pattern is found when the result 
of each comparison performed in said compar- 
ing step is that said first byte of said packet be- 
ing compared matches the value of said sync 



byte. 

24. The invention as defined in claim 20 wherein said 
searching step further includes the step of: 

5 

determining whether a payload of said IP pack- 
et has a length equal to an integral multiple of 
a length of an MPEG-2 transport stream pack- 
et, 

10 comparing the value of a first byte at a first lo- 

cation within said packet and each byte at an 
offset of a length of an MPEG-2 transport 
stream packet therefrom with the value of an 
MPEG-2 sync byte; and 

*5 signaling said pattern is found when the result 

of a majority of comparisons performed in said 
comparing step is that said first byte of said 
packet being compared matches the value of 
said sync byte. 

20 

25. The invention as defined in claim 20 wherein said 
searching step further includes the step of: 

determining whether a payload of said I P pack- 
25 et has a length equal to an integral multiple of 

a length of an MPEG-2 transport stream pack- 
et, 

comparing the value of a first byte at a first lo- 
cation within said packet and each byte at an 
30 offset of a length of an MPEG-2 transport 

stream packet therefrom with the value of an 
MPEG-2 sync byte; and 
signaling said pattern is found when the result 
of at least a majority of comparisons performed 
35 in said comparing step is that said first byte of 

said packet being compared matches the value 
of said sync byte and said packet was indicated 
to contain an error. 

40 26. The invention as defined in claim 20 wherein said 
payload is at least one of a set of payloads within 
an IP packet, said set consisting of: a) an IP data 
payload, b) an unreliable datagram protocol (UDP) 
data payload that does not include a real time pro- 
45 tocol (RTP) header, c) that portion of a UDP data 
payload after an RTP header that is included in said 
UDP data payload, and d) a transmission control 
protocol (TCP) data payload. 

50 27. The invention as defined in claim 20 further com- 
prising the step of processing said IP packet with a 
priority assigned for packets containing video when 
said indicating step indicates that said IP packet 
contains video. 

55 

28. The invention as defined in claim 20 wherein said 
pattern corresponds to the value of an MPEG-2 
sync byte regularly spaced from an initial position 
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through the end of said payload, said regular spac- 
ing being equal to the length of an MPEG-2 trans- 
port stream packet, said initial position being locat- 
ed within the length of a real time protocol header 
and the length of one MPEG-2 transport stream s 
packet from a start of said payload. 



searching through a payload of said IP packet 
for a pattern indicative of video; and 
indicating that said IP packet contains video 
when said pattern is found; and 
indicating that said IP packet does not contain 
video when said pattern is not found. 



29. The invention as defined in claim 20 wherein said 
pattern corresponds to the value of an MPEG-2 
sync byte and the end of said IP packet spaced 
apart by the length of one M P EG-2 transport stream 
packet, said initial position being located within the 
length of a real time protocol header and the length 
of one M PEG-2 transport stream packet from a start 
of said payload. 

30. The invention as defined in claim 20 wherein said 
pattern corresponds to the value of an MPEG-2 
sync byte regularly spaced from an initial prescribed 
position, said regular spacing being equal to the 
length of an MPEG-2 transport stream packet. 



36. The invention as defined in claim 35 further com- 
prising the step of processing said IP packet with a 

10 priority assigned for packets containing video when 
it is indicated that said IP packet contains video. 

37. The invention as defined in claim 35 wherein said 
pattern corresponds to the value of an MPEG-2 

15 sync byte regularly spaced from an initial position 
through the end of said payload, said regular spac- 
ing being equal to the length of an MPEG-2 trans- 
port stream packet, said initial position being locat- 
ed within the length of a real time protocol header 
20 and the length of one MPEG-2 transport stream 
packet from a start of said payload. 



15 



20 



31. A method for processing an internet protocol (IP) 
packet, comprising the steps of: 

searching through a payload of said IP packet 
for a pattern indicative of the presence of mo- 
tion picture expert group (MPEG)-2 video; and 
indicating that said IP packet contains MPEG- 
2 video when said pattern is most likely found. 

32. The invention as defined in claim 31 wherein said 
pattern corresponds to an MPEG-2 sync byte reg- 
ularly spaced from an initial prescribed position, 
said regular spacing being equal to the length of an 
MPEG-2 transport stream packet. 

33. The invention as defined in claim 32 wherein said 
initial prescribed position is a position within the 
group of positions consisting of: a) the first byte in 
an IP data payload of said packet, b) the first byte 
of a UDP payload of said IP packet, c) the first byte 
after an RTP header of an unreliable datagram pro- 
tocol (UDP) payload of said IP packet, d) the first 
byte of a transport control protocol (TCP) payload 
of said IP packet, and e) the first byte of a TCP pay- 
load after a header contained therein indicating real 
time information is contained in said IP packet. 

34. The invention as defined in claim 31 further com- 
prising the step of processing said IP packet with a 
priority assigned for packets containing video when 
said indicating step indicates that said IP packet 
contains video. 

35. A method for processing an internet protocol (IP) 
packet, comprising the steps of: 



38. The invention as defined in claim 35 wherein said 
pattern corresponds to the value of an MPEG-2 

25 sync byte regularly spaced from an initial prescribed 
position, said regular spacing being equal to the 
length of an MPEG-2 transport stream packet. 

39. The invention as defined in claim 38 wherein said 
30 initial prescribed position is a position within the 

group of positions consisting of: a) the first byte in 
an IP data payload of said packet, b) the first byte 
of a UDP payload of said IP packet, c) the first byte 
after an RTP header of an unreliable datagram pro- 
35 tocol (UDP) payload of said IP packet, d) the first 
byte of a transport control protocol (TCP) payload 
of said IP packet, ande) the first byte of a TCP pay- 
load after a header contained therein indicating real 
time information is contained in said IP packet. 

40 

40. A computer program in the form of machine reada- 
ble instructions, said computer program being for 
causing a system including a processor to: 

45 search through a payload of an internet proto- 

col (IP) packet for a pattern indicative of the vid- 
eo; 

indicate that said IP packet contains video 
when said pattern is found; and 
50 indicate that said IP packet does not contain 

video when said pattern is not found. 

41. The invention as defined in claim 40 wherein said 
computer program further causes said processor to 

55 process said I P packet with a priority assigned 

for packets containing video when said IP packet is 
indicated to contain video. 
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42. Apparatus comprising: 

a processor; 

a memory coupled to said processor for storing 
a received internet protocol (IP) packet; and 
a program store; 

wherein said program store contains instruc- 
tions for causing said processor to 

search through a payload of an internet proto- 
col (IP) packet for a pattern indicative of the vid- 
eo; 

indicate that said IP packet contains video 
when said pattern is found; and 
indicate that said IP packet does not contain 
video when said pattern is not found. 

43. Apparatus, comprising: 

20 

means for searching through a payload of an 
internet protocol (IP) packet for a pattern indic- 
ative of video; and 

means for indicating that said IP packet con- 
tains video when said pattern is found. 25 
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